I wish there was a non-class way to handle error boundaries

I'm not sure this test actually adds much value. in #27 I discovered that a rejected Promise does not trigger the error boundary, and instead it's up to the suspending code to throw the error on the subsequent render (see line 24 for example), which means this is actually no different than if the hook just threw an error for some other reason (like we already do in the errorHook test suite.

Anyone who implements a Suspense library will be doing such so I think this provides value

Yeah, that was my thought too and why I kept it when cleaning up the commits.

If you kept this block an just re-threw you could also grab any promises to store in a third result value of 'promise' or the like. While waitForNextUpdate() will work in most cases, inspecting the promise thrown would be useful in test cases.

(If you rethrow the exact same error it will preserve the original stack trace.)

The intention of removing this and using a Suspense and ErrorBoundary wrapper was to protect this library from having to deal with the internals of how error handling and suspended rendering actually works. The fact that a thrown promise is what triggers react to suspend is an implementation for React, rather than something we should be relying on.

you're still setting error property though, right? Seems like you are somewhat depending on react in that manner. regardless - this is a react hooks testing library. very specific to how react works.

Yes, error is being set, but it's coming from the exposed componentDidCatch API, so we don't care how React gets it to that point, just deal with it when it gets there. When we look at the Suspense equivalent, React does not expose this to us in any way, so if we want to handle it, we essentially need to recreate react's internal logic in order to treat it the same way. If React changes the specifics on how it deals with promises, we would also need to change.

if waitForNextUpdate() works

It should. I'd rather fix holes where it doesn't than maintain custom suspense handling.

• the promise to be caught so it doesn't throw above

This solution would not end up throwing out of the renderHook function, if that's what you mean?

• a mechanism to see when it is called

Can you unpack this a bit more? Are you concerned about when an update was triggered by something other than the promise resolving, or something else?

One path is that no promise is thrown from the hook - I want to test that it actually threw a promise, and THEN did something else

I guess I'm questioning the value of having that much pwoer to inspect the internals of what's happening in your hook (i.e. white box test) vs. just asserting the output from the given inputs (i.e. black box test).

In my experience, white box test are very fragile to changes in the system and need constant updating as the internals shift around (e.g. you might change the condition for when the promise is thrown, so now would need to move things around in your tests to match the change). The black box tests are more likely to continue to work so, long as the contract of the inputs and outputs hasn't changes (otherwise the test must be changed anyway in both testing styles).

In cases where you need more control over when and how the promise thrown, then you may be better off extracting it into some form of factory pattern and mocking that behaviour in the hook test, and testing those variations of the factory seperately to the hook itself.

As an escape hatch, if you really need access to the promise itself, I think you could just catch it in the hool callback itself

let promise
const { result } = renderHook(() => {
  promise = null // assuming you want to reset it between renders
  try {
    useSomething()
  } catch (e) {
    if (e.then) {
      promise = e
    }
  }
})

const promiseValue = await promise

expect(promiseValue).toBe('whatever')

I'm still unsure how that is more useful than

const { result, waitForUpdate } = renderHook(() => useSomething())

await waitForUpdate

expect(result.current).toBe('whatever you expect after the prmise resolved')

As in both cases

• if the promise resolves, and the expectation is met, the the test passes
• if the promise resolves, and the expectation is not met, the test fails
  • in the first example all you would know the promise value changed
  • in the second example you would only know something went wrong to affect the output
• if the promise rejects, the test fails with the thrown error
• if the promise is not thrown, the test will fail
  • in the first example it would probably be about trying to await null
  • in the second example the test would timeout waiting for an update that never comes

I'm also leaning away from explicitly handling supsense as it would get very difficult to manage if you had a hook throw a promise, and then once resolved throw another promise, etc. Suspense would keep that component suspending untill it eventually rendered something, whereas keeping track of each one and what they were up to could get complicated.

I mean, I would argue that suspense is very much an explicit interface and not an implementation detail - as anyone using the hook that throws promises will need to define suspense boundaries themselves. It's not about how but if.

Yes it could throw many times - that should be up to the test writer to understand exactly what that behavior should be - or if it even cares at all. I agree in many cases you won't care, and you can simply waitForUpdate. But there are certainly cases where you will.

(I responded slowly this time due to company hackathon last week and then I was out traveling over weekend)